Polymorphic Endpoint Types for Copyless Message Passing

We present PolySing#, a calculus that models process interaction based on copyless message passing, in the style of Singularity OS. We equip the calculus with a type system that accommodates polymorphic endpoint types, which are a variant of polymorphic session types, and we show that well-typed processes are free from faults, leaks, and communication errors. The type system is essentially linear, although linearity alone may leave room for scenarios where well-typed processes leak memory. We identify a condition on endpoint types that prevents these leaks from occurring.Comment: In Proceedings ICE 2011, arXiv:1108.014

Lucretia - intersection type polymorphism for scripting languages

Scripting code may present maintenance problems in the long run. There is, then, the call for methodologies that make it possible to control the properties of programs written in dynamic languages in an automatic fashion. We introduce Lucretia, a core language with an introspection primitive. Lucretia is equipped with a (retrofitted) static type system based on local updates of types that describe the structure of objects being used. In this way, we deal with one of the most dynamic features of scripting languages, that is, the runtime modification of object interfaces. Judgements in our systems have a Hoare-like shape, as they have a precondition and a postcondition part. Preconditions describe static approximations of the interfaces of visible objects before a certain expression has been executed and postconditions describe them after its execution. The field update operation complicates the issue of aliasing in the system. We cope with it by introducing intersection types in method signatures.Comment: In Proceedings ITRS 2014, arXiv:1503.0437

A CuCh Interpretation of an Object-Oriented Language1 1Partially supported by MURST Cofin '99 TOSCA.

AbstractBöhm's CuCh machine extends the pure lambda-calculus with algebraic data types and provides the possibility of defining functions over disjoint sums of algebras. We exploit such natural form of overloading to define a functional interpretation of a simple, but significant fragment of a typical objectoriented classbased language

Trait-oriented Programming in Java 8

International audienceJava 8 was released recently. Along with lambda expressions, a new language construct is introduced: default methods in interfaces. The intent of this feature is to allow interfaces to be extended over time preserving backward compatibility. In this paper, we show a possible, different use of interfaces with default methods: we introduce a trait-oriented programming style based on an interface-as- trait idea, with the aim of improving code modularity. Starting from the most common operators on traits, we introduce some programming patterns mimicking such operators and discuss this approach

Delegation by Object Composition

AbstractClass inheritance and method overriding, as provided by standard class-based languages, are often not flexible enough to represent objects with some dynamic behavior. In this respect, object composition equipped with different forms of method body lookup is often advocated as a more flexible alternative to class inheritance since it takes place at run time, thus permitting the behavior of objects to be specialized dynamically. In this paper, we illustrate Incomplete Featherweight Java (IFJ), an extension of Featherweight Java with a novel linguistic construct, the incomplete object. Incomplete objects require some missing methods which can be provided at run time by composition with another (complete) object. Furthermore, we present two mechanisms for the method body lookup on (composed) objects, one based on delegation and the other based on consultation. Thanks to the design of the language, the consultation-based lookup is a simple extension of the delegation-based one. Both mechanisms are disciplined by static typing, therefore the language enjoys type safety (which implies no “message-not-understood” run-time errors) and avoids possible accidental overrides due to method name clashes